Hardcoded VPS root credentials exposed in repository

The VPS root password 9'hG8lV1RCU)sesnQ3hA along with the server IP and username are hardcoded in multiple shell scripts and markdown documentation files being committed to the repository. This exposes production server credentials to anyone with repository access. The credentials appear in connect-vps.sh, setup-ssh-keys.sh, vps-backup.sh, vps-manager.sh, and VPS_CONNECTION_README.md. Credentials should be stored in environment variables or a secrets manager, not committed to version control.

Function uses undefined event variable causing runtime error

The showTab function references event.target on lines 420-421, but event is never passed as a parameter to the function. The function is called from DOMContentLoaded on line 631 as showTab('execute') where no click event exists, causing event to be undefined and resulting in a runtime error that prevents the dashboard tabs from initializing properly.

Remove hardcoded VPS root password

This script embeds the VPS root password in the repository (VPS_PASSWORD=...). Anyone with read access to the repo can log into the server, and the secret is permanently exposed in git history even if later removed. This is a critical security leak for any environment where the VPS is reachable; move the credential to a secret manager/env var and rotate the password immediately.

Useful? React with 👍 / 👎.

Do not disable SSH host key verification

The SSH invocation explicitly disables host key checking and discards known_hosts. If a user runs this script on a compromised network or with DNS/route hijacking, sshpass will send the root password to a spoofed host without any warning. This materially weakens SSH’s protections; prefer trusting a pinned host key (e.g., pre-populate known_hosts) instead of StrictHostKeyChecking=no.

Useful? React with 👍 / 👎.

The same VPS credentials are hardcoded here. This creates multiple locations where the password is exposed. Credentials should be centralized in a secure configuration file that is not committed to the repository.

Hardcoded credentials exposed. The password should be stored securely, not committed to version control. Use environment variables or secure credential management.

Hardcoded password in plain text. This is a critical security vulnerability. Use environment variables or secure secret management instead.

Hardcoded VPS password exposed. Use environment variables or a secure configuration file that is excluded from version control via .gitignore.

Hardcoded authentication token in JavaScript code. This token is exposed to anyone who views the page source. Move authentication tokens to server-side code and implement proper API authentication mechanisms.

Both connect_vps and scp_vps use ssh/scp with -o StrictHostKeyChecking=no and -o UserKnownHostsFile=/dev/null, disabling SSH host key verification for this production VPS. This makes it trivial for a network-positioned attacker to impersonate the VPS, intercept backups, and capture root credentials while the script appears to run normally. Restore strict host key checking with a persistent known_hosts entry for the VPS instead of discarding host keys, and avoid disabling these options in automated backup tooling.

Both SSH host entries set StrictHostKeyChecking no and UserKnownHostsFile /dev/null, which disables SSH host key verification and prevents keys from ever being persisted. This makes it trivial for a network attacker to spoof 147.93.120.99 and transparently intercept or tamper with all SSH sessions started via ssh vps-hostinger or ssh hostinger. Remove these options so OpenSSH performs normal host key checking and uses the default known_hosts file, only relaxing checks in exceptional, tightly-controlled bootstrap scenarios if absolutely necessary.

The fallback SSH path in connect_vps disables host key verification by passing -o StrictHostKeyChecking=no and -o UserKnownHostsFile=/dev/null to ssh. With these options an attacker on the network can spoof the VPS IP, capture the hardcoded root password, and execute arbitrary commands under root while the script appears to succeed. Require standard SSH host key checking with a persistent known_hosts entry for the VPS instead of disabling these protections in automation.

All of the SSH operations in this script (ssh-copy-id and fallback ssh commands) are invoked with -o StrictHostKeyChecking=no and -o UserKnownHostsFile=/dev/null, which disables server identity verification. During key setup this allows a man-in-the-middle on the network to impersonate the VPS, capture the root password, and insert their own key into authorized_keys. Restrict the use of relaxed options to a one-time, explicitly verified bootstrap (or avoid them entirely) and enforce normal host key checking with a persistent known_hosts entry for subsequent runs.

The SSH command here disables host key verification using -o StrictHostKeyChecking=no and -o UserKnownHostsFile=/dev/null, which makes man-in-the-middle attacks against this VPS much easier because server identities are never verified or pinned. An attacker controlling the network could impersonate the VPS IP and capture the hardcoded root credentials or inject arbitrary commands. Re-enable strict host key checking and use a persistent known_hosts file, pinning the VPS host key and only bypassing checks in tightly controlled bootstrap flows.